This disclosure relates generally to message exchange systems, and more particularly to message exchange scenario definition techniques and systems.
Message exchange systems, such as SAP AG's exchange infrastructure (XI), are used to integrate external systems using proprietary, legacy or standard messaging formats. In SAP's XI, for example, senders and receivers are separated from one another, and exchange messages using an Integration Server. This separation makes it easier to connect systems that are technologically different. Every system that can exchange messages with the Integration Server can also exchange messages with all other systems that are connected to the Integration Server.
SAP's XI supports direct communication using proxies, which are generated in the application systems using a description in WSDL (Web Service Description Language). XI also supports communication using adapters. In this case, interfaces for message exchange are created in the application system, or existing interfaces are used. Simple message processing on the Integration Server is stateless, e.g., the Integration Server does not know of any connections between various messages.
Cross-component integration processes, on the other hand, describe related processes, which can use the knowledge about messages that have already been processed to further control the process (for example, waiting for the corresponding response for a message in order to start further actions). SAP's XI enables enterprises to model, change, and manage these cross-component integration processes centrally. These processes are executed on the Integration Server and are included in message processing by configuration.
After starting with pilot projects for introducing a message exchange system in their enterprises, customers increasingly use those systems for bigger and more business-critical scenarios with a large message load. However, message exchange systems such as XI are very complex tools which only provide a limited means for controlling and monitoring. Thus, it is getting more and more difficult to detect errors and erroneous situations and to prove that the message exchange system is in a healthy state.
Today's XI or similar system only offers a possibility to monitor messages by explicitly giving selection criteria in the monitors of the different messaging components (integration server and adapter engine). It does not have a notion of a cross-component message scenario where a subset of all the message traffic can be defined according to certain message execution attributes. Such a notion is necessary for effective use of XI under high message load so that only certain relevant subsets of the messages can be monitored by dedicated users responsible for these message subsets (e.g. messages with high priority). No scenario notion is currently available in XI monitoring tools, and therefore relevant messages can only be selected explicitly in the different message monitors by providing all selection attributes.